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REMARKS 

The present Amendment amends claims 1, 3 and 11-13, and leaves claims 2, 
4-10, 14, and 15 unchanged. Therefore, the present application has pending claims 
1-15. 

Claim Objections 

Claim 3 is objected to due to an informality noted by the Examiner. 
Amendments were made to claim 3 to correct the informality. Therefore, this 
objection is overcome and should be withdrawn. 
35 U.S.C. §11 2 Rejections 

Claim 1 is rejected under 35 U.S.C. §112, second paragraph as allegedly 
failing to particularly point out and distinctly claim subject matter which Applicants 
regard as the invention. This rejection is traversed for the following reasons. 
Applicants submits that claim 1 , as now more clearly recited, is in compliance with 
the provisions of 35 U.S.C. §112. 
35 U.S.C. §102 Rejections 

Claims 1-15 are rejected under 35 U.S.C. §1 02(e) as being anticipated by 
U.S. Patent No. 6,977,927 to Bates et al. ("Bates")- This rejection is traversed for the 
following reasons. Applicants submit that the features of the present invention as 
now more clearly recited in claims 1-15 are not taught or suggested by Bates, 
whether taken individually or in combination any of the other references of record. 
Therefore, Applicants respectfully request the Examiner to reconsider and withdraw 
this rejection. 

Amendments were made to the claims to more clearly describe features of the 

present invention. Specifically, amendments were made to the claims to more 

clearly recite that the present invention is directed to a network storage system for 
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supplying a storage to a plurality of clients and a network storage system connected 
to a network to which a plurality of clients are connected as recited, for example, in 
independent claims 1, 11 and 12. 

The present invention, as recited in claim 1 , and as similarly provided in 
claims 1 1 and 12, provides a network storage system for supplying a storage to a 
plurality of clients through a network. The system includes a first device and a 
second device. The first device is provided with a disk device, and the second 
device manages a connection to the clients. According to the present invention, the 
first device allocates an area of the disk device to the second device. Also, the 
second device allocates a portion of the area allocated from the first device to each 
of the plurality of clients. In addition, according to the present invention, the second 
device is provided with a means for translating a source network address to a 
specific network address of the second device, where the specific network address is 
transferred to the first device. In the present invention, the means for translating 
always translates each of a plurality of network addresses of each of the clients to 
the specific network address of the second device. The prior art does not disclose 
all of these features. 

The above described features of the present invention, as now more clearly 
recited in the claims, are not taught or suggested by any of the references of record, 
particularly Bates, whether taken individually or in combination with any of the other 
references of record. 

Bates teaches a method and system of allocating storage resources in a 

storage area network. However, there is no teaching or suggestion in Bates of the 

network storage system for supplying a storage to a plurality of clients or the network 

storage system connected to a network to which a plurality of clients are connected, 
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as recited in claim 1 , and as similarly recited in claims 1 1 and 1 2 of the present 
invention. 

Bates discloses a system for allocating storage resources in a storage area 
network. A logical unit number (LUN) mapper receives at least one storage request 
parameter and maps the storage request parameters to at least one physical LUN. 
The LUN mapper includes at least one LUN map. The storage request parameters 
include a host id parameter, a target LUN parameter, and a target host bus adaptor 
(HBA) parameter. The LUN mapper uses the host id parameter to select the one of 
the LUN maps that corresponds to the host id parameter. The LUN mapper applies 
the target LUN parameter and the target HBA parameter to the selected LUN map to 
locate the physical LUN(s) stored in the selected LUN map. The LUN mapper issues 
the received read/write storage request to at least one storage device that houses 
the physical LUN(s). The one or more storage devices are located in the storage 
area network. 

One feature of the present invention, as recited in claim 1 , and as similarly 
recited in claims 1 1 and 12, includes where the first device allocates an area of the 
disk device to the second device, and where the second device allocates a portion of 
the area allocated from the first device to each of the plurality of clients. Contrary to 
the Examiner's assertions, Bates does not disclose this feature. To support the 
assertion that Bates teaches this feature, the Examiner cites: column 4, lines 10-20; 
column 3, line 54 to column 4, line 5; and column 10, lines 5-20). However, neither 
the cited text nor any other portions of Bates teach or suggest the claimed features. 

For example, column 4, lines 10-20 of Bates provides a description of Fig. 1, 

which illustrates a block diagram of an example storage allocator network 

configuration. As described, the storage 106 receives storage read/write requests 
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from the storage allocator 104. The storage 106 routes the received read and write 

requests to the corresponding storage device(s), which respond by reading or writing 

as requested. Storage 1 06 may comprise one or more of a variety of storage 

devices, including tape systems, JBODs Gust a bunch of disks), floppy disk drives, 

etc. In the cited text, there is no teaching or suggestion of where the first device 

(storage allocator 104) allocates an area of the disk device (storage 106) to the 

second device (server 102), and where the second device allocates a portion of the 

area allocated by the first disk device to each of the plurality of clients, in the manner 

claimed. For instance, as shown in Fig. 2 of Bates, the allocation occurs solely in the 

storage allocator 104. As such, Bates does not teach or suggest where the second 

device (server 102) further allocates an area allocated by the first device, to each of 

the plurality of clients, in the manner claimed. 

By way of further example, column 3, line 54 to column 4, line 5 of Bates also 

provides a description of Fig. 1 , which illustrates a block diagram of a storage 

allocator network configuration. As described, the storage allocator 104 receives 

storage read and write requests from the server 102. The storage read and write 

requests include one or more locations in a logical data space recognized by the 

requesting host. The storage allocator 104 uses a parsed read and write request to 

determine physical storage locations corresponding to the target locations in the 

logical data space. One or more LUN (logical unit number) maps in storage allocator 

104 are used to map virtual data locations to physical locations in storage 106. 

Storage allocator 104 outputs read and write requests to physical storage/LUNs. 

This is quite different from the present invention. More specifically, in Bates, there is 

no teaching or suggestion of where the first device (storage allocator 104) allocates 

an area of the disk device (storage 106) to the second device (server 102), and 
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where the second device allocates a portion of the area allocated by the first disk 
device to each of the plurality of clients, in the manner claimed. For instance, as 
shown in Fig. 2 of Bates, the allocation occurs solely in the storage allocator 104. 
Therefore, Bates does not teach or suggest where the second device (server 102) 
further allocates an area allocated by the first device, to each of the plurality of 
clients, in the manner claimed. 

By way of even further example, column 10, lines 5-20 of Bates provides a 
description of Fig. 2, which illustrates a block diagram of a storage allocator. The 
cited text describes where a LUN mapper 206 of the storage allocator 104 receives 
the extracted parameters from read/write storage request parser 204. LUN mapper 
206 stores LUN maps corresponding to servers and hosts. Available storage is 
partitioned in the LUN maps without any regard necessarily to the physical divisions 
of the storage devices. These partitions are referred to as virtual or target LUNs. 
Each host or server may be presented with different portions of physical storage via 
the LUN maps, or some hosts may have the same portions presented. Unlike the 
present invention, the cited text of Bates does not teach or suggest where the first 
device (storage allocator 104) allocates an area of the disk device (storage 106) to 
the second device (server 102), and where the second device allocates a portion of 
the area allocated by the first disk device to each of the plurality of clients, in the 
manner claimed. For instance, as shown in Fig. 2 of Bates, the allocation occurs 
solely in the storage allocator 104. Accordingly, Bates does not teach or suggest 
where the second device (server 1 02) further allocates an area allocated by the first 
device, to each of the plurality of clients, in the manner claimed. 

Another feature of the present invention, as recited in claim 1 , and as similarly 

recited in claim 1 1 , includes where the second device is provided with a means for 
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translating a source network address to a specific network address of the second 
device, and where the means for translating always translates each of a plurality of 
network addresses of each of the clients to the specific network address of the 
second device. Bates does not disclose this feature. To support the assertion that 
Bates teaches a means for translating, the Examiner cites: column 1 1 , lines 21-25 
and column 1 1 , lines 57-67. However, neither the cited text, nor any other portions 
of Bates, teach or suggest the claimed features. 

For example, column 1 1 , lines 21 -25 of Bates provides a description of the 
LUN mapper 206 (Fig. 2) and the LUN map 308 (Fig. 3). As described, the LUN 
mapper 206 uses the received host ID parameter to determine which of the stored 
LUN maps to use. For example, LUN map 308 may be the proper LUN map 
corresponding to the received host ID. This feature of Bates is quite different from 
the present invention. For instance, there is no teaching or suggestion in the cited 
text of a means for translating a source network address to a specific network 
address of the second device, where the means for translating always translates 
each of a plurality of network addresses of each of the clients to the specific network 
address of the second device, in the manner claimed. More specifically, Bates does 
not teach or suggest translating a source network address, for each client, to the 
same network address of the second device, as claimed. 

By way of further example, column 1 1 , lines 57 to 67 of Bates provides a 

description of Fig. 5, which is an illustration of a storage area network. As described, 

host computers 502, 504 and 506 are servers on a communications network. 

Storage allocators 508 and 510 parse storage read and write requests received from 

host computers 502, 504 and 506, and use the parsed read and write requests to 

determine physical data locations in storage devices 512, 514, 516, and 518. 
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Storage devices 512, 514, 516, and 518 receive physical storage read and write 
requests from storage allocators 508 and 510, and respond by reading data from or 
writing data to storage as requested. This feature of Bates is quite different from the 
present invention. For instance, there is no teaching or suggestion in the cited text 
of a means for translating a source network address to a specific network address of 
the second device, where the means for translating always translates each of a 
plurality of network addresses of each of the clients to the specific network address 
of the second device, in the manner claimed. More specifically, Bates does not 
teach or suggest translating a source network address, for each client, to the same 
network address of the second device, as claimed. 

Therefore, Bates fails to teach or suggest "wherein said first device allocates 
an area of said disk device to said second device " and " wherein said second device 
allocates a portion of said area allocated from said first device to each of said 
plurality of clients " as recited in claim 1, and as similarly recited in claims 11 and 12. 

Furthermore, Bates fails to teach or suggest " wherein said second device is 
provided with means for translating a source network address to a specific network 
address of the second device, the specific network address to be transferred to said 
first device, such that the means for translating always translates each of a plurality 
of network addresses of each of said plurality of clients to the specific network 
address of the second device " as recited in claim 1 , and as similarly recited in claim 
11. 

Therefore, Bates does not teach or suggest the features of the present 
invention, as recited in claims 1-15. Accordingly, reconsideration and withdrawal of 
the 35 U.S.C. §102(e) rejection of claims 1-15 as being anticipated by Bates are 
respectfully requested. 
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The remaining references of record have been studied. Applicants submit 
that they do not supply any of the deficiencies noted above with respect to the 
references used in the rejection of claims 1-15. 

In view of the foregoing amendments and remarks, Applicants submit that 
claims 1-15 are in condition for allowance. Accordingly, early allowance of claims 1- 
15 is respectfully requested. 

To the extent necessary, the Applicants petition for an extension of time under 
37 CFR 1 .136. Please charge any shortage in fees due in connection with the filing 
of this paper, including extension of time fees, or credit any overpayment of fees, to 
the deposit account of Mattingly, Stanger, Malur & Brundidge, P.C., Deposit Account 
No. 50-1417 (referencing attorney docket no. H-1105). 



Respectfully submitted, 



MATTINGLY, STANGER, MALUR & BRUNDIDGE, P.C. 




Donna K. Mason 
Registration No. 45,962 



DKM/cmd 
(703) 684-1120 
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Amendments to the Drawings 

Amendments were made to Figs. 1 and 22 to correct the misspelling of 
"AMINSTRATION" to "ADMINISTRATION". 

Amendments were made to Figs. 1 , 8, 10, 12-14 and 22 to correct the 
misspelling of "TRANSRATION" to "TRANSLATION". 

Marked-Up Drawings and Annotated Replacement Drawings are enclosed. 
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